1. Field of the Invention
The present invention relates to a software executing device and a co-operation method, which are used, for example, in a hardware/software co-simulation environment.
2. Related Art
Hardware/software co-simulation (HW/SW co-simulation) is used to shorten time to market (TTM) for a system on chip (SoC) by starting verification of software/firmware (SW/FW) using HW simulation before the SoC is completed, or to reduce production man-hours of a test vector for verification by giving a test input to an HW description which is an object of verification, from a central processing unit (CPU) model of an SW simulation environment.
In order to start the verification of software before the SoC is completed, it is necessary to simulate hardware operations in addition to an environment for performing software simulation (referred to as an SW simulator below). Simulating the operations is roughly classified into a method of simulating an existing HW description itself, and a method of creating an HW model for simulation which operates at a higher speed. Also, a scheme of writing the existing HW description on an FPGA board or the like and bringing the FPGA board into collaboration with a simulator has begun to be used recently (for example, FPGA board, ZeBu series, manufactured by EVE (http://www.eve-team.com/, Nihon EVE K.K., http://www.eve-japan.co.jp/)).
By performing co-simulation of the FPGA board and the SW simulator, the HW description can be operated at a high speed. There is also such an advantage that existing HW assets and intellectual property (IP) can be directly used.
Since it is not necessary to create a new HW model for simulation, such advantages are also considered to be obtained that turn around time (TAT) for verifying software can be shortened, cost reduction can be expected, and at the same time, the issue of accuracy of the HW model for simulation can be cleared.
On the other hand, in the co-simulation of the SW simulator and the FPGA board, the SW simulator is software operating on a general-purpose computer, and the FPGA board is hardware implemented on a dedicated board or the like and connected to the general-purpose computer. Thus, it is important how to synchronize operations between the SW simulator and the FPGA board.
Concerning synchronization between the SW simulator and the FPGA board, a per-cycle synchronization scheme, a scheme of using a bus transactor, a scheme of controlling a synchronization interval in an SW simulator side, a scheme of determining whether there is an interrupt possibility, or the like are conventionally known.
The per-cycle synchronization scheme is a scheme in which a clock signal is generated from the SW simulator side and the FPGA board is operated based on the clock signal. In the scheme, it is necessary to shorten a synchronization interval in order to perform accurate simulation. Thus, there is such a problem that a decrease in a simulation speed is caused.
The scheme of using a bus transactor is a scheme in which access from the SW simulator side to the FPGA board is always performed by a bus transaction (granularity at a bus-command level such as READ and WRITE) and the bus transaction is converted to a cycle level signal by the bus transactor on the FPGA board, so as to operate the HW description written on the FPGA board. A scheme in which a synchronization command (for example, “advance for 100 clocks”) is issued from the SW simulator side other than during occurrence of the bus transaction to control operations in the FPGA board side is the scheme of controlling a synchronization interval in the SW simulator side. All of these schemes are schemes of controlling a synchronization period and interval in the software side. Since it is difficult to accurately handle a time of occurrence of an event (an interrupt request or the like) from the hardware side, there is such a problem that simulation accuracy is reduced.
The scheme of determining whether there is an interrupt possibility is disclosed in JP-A 2001-290860(Kokai). The scheme improves a simulation processing speed by determining in advance in the SW simulator side whether there is a possibility that an interrupt occurs from an HW simulator side, and performing no synchronization with a part of hardware where there is no interrupt possibility. In the scheme, concerning whether an interrupt occurs, what “incorporated software” operating on a “CPU simulating unit” writes to an address mapped into a register of an interrupt controller is monitored and how the “incorporated software” sets interrupts from respective “peripheral circuits” is recorded during simulation execution, so as to determine whether there is an interrupt from the HW simulator on SW simulation. Since specifications (a register address, a method of controlling the interrupts from respective peripheral circuits) of the “interrupt controller” which differ in each SoC are incorporated in the CPU simulating unit in this scheme, it is necessary to create a CPU simulating unit for each SoC, or to configure settings so that the specifications of the “interrupt controller” which differ in each SoC are simulated. Thus, the simulator has poor general-purpose properties. Also, a mechanism for simulating the specifications of the “interrupt controller” which differ in each SoC means that an interrupt controller model for simulation is created, and the same problem as that in creating the HW model for simulation described above could be caused.